This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this doeument are accurate representations of the 
original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problems Mailbox. 



Experiences in developing 
multi-technology TMN systems 



Lennart K Bjerring Lars Bo Serensen Carsten Gym 
Claus Grabowski Sonny Rasmussen 
Seren Dittman 
Rene S. Lund 



L. M. Ericsson A/S UH Communications ApS 
Sluseholmen 8 Telegrafvej 5, 3. 

DK- 1 790 Copenhagen V DK-2750 Ballerup 
Denmark Denmark 



Tele Danmark A/S 

Telegade 2 
DK-2630 T&strup 
Denmark 



ABSTRACT 

Integration of management systems across technological and administrative domain boundaries is a necessary 
prerequisite for automating or optimising service management. Despite many years of standardisation effort the 
number of management technologies and interface specifications seems to continue to increase. An architectural 
approach to integrated network management, therefore, cannot be based on any single architecture or 
technology, but must instead be based on recognition of diversity and interoperability. The TMN-architecture is 
basically such an integration architecture, although OSI is sometimes assumed to be the only realisation option. 

This paper presents experiences with the approach taken to realise integrated network management in the 
European ACTS project Prospect (project number AC052). Several layers of integration have been realised, 
including multi-vendor and inter-domain management, and several management technologies have been 
integrated, namely CORBA, OSI and SNMP. 

BACKGROUND 

At the NOMS'96 conference the RACE project PREPARE presented the development and validation of a 
TMN-based inter-domain management architecture [Lewis96]. The paper in particular reported on issues related 
with multi-vendor TMN - i.e., TMN-platforms from multiple vendors - and multi-TMN configurations - i.e., 
multiple network operators and owners. This work was mainly validated based on OSI/CMIP. 

In Prospect, which is a follow-up on PREPARE, a more broad validation takes place, in terms of management 
protocols and technologies, but also in terms of the "vertical scope" of management. PREPARE was mainly 
concerned with managing communications, whereas Prospect also is concerned with managing information 
services working on top of the communication infrastructure. The range of management technologies include 
OSI, SNMP, CORBA as well as internet, Web, Java, and others. The range of architectural inputs is extended to 
include also CORBA/OMG and TINA [Lewis97]. 
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THE PROSPECT SERVICES 



The Prospect consortium has set up a pan-European network infrastructure, composed of public and customer 
premises networks (LANs). The role of the integrated network management system presented in the following is 
to provide integrated, end to end management of this infrastructure. The system provides corresponding 
management services to a set of IP-based multi-media tele-services, delivered to users located in the diverse 
Customer Premises Network (CPN) in the form of an integrated tele-education service package [Lewis97]. The 
main challenge to deal with in order to realise integrated network management is heterogeneity. Heterogeneity 
means that "things" are different in some respect. "Things" may be network elements, management systems, 
components and functions, etc. Differences may be in various respects. Of these, our primary concern is derived 
from characteristics of an open telecom service market: administrative differences, caused by different owners 
each defining and enforcing their own policies, such as access control and accountability; technological 
differences, caused by differences in communications technologies; (service) model differences, which is the 
result of deploying components for different purposes and applications. One of the results is that different 
components will offer different services to its users. Another result is that the same service may be offered by 
different components, in a way that is difficult to discover. 

To deal with the heterogeneity, the overall system architecture is based on a distinction between the three types 
of domain, which reflect the three types of heterogeneity that characterise the network infrastructure: 
administrative domain: the network infrastructure is partitioned into administrative domains, representing the 
owners of the various parts of the infrastructure; (network) technology domain: the various administrative 
domains encapsulate diverse network technologies; (management) model domain: the various network 
technology domains are manageable by diverse model abstractions and capabilities. To bridge the boundaries 
between these types of domain an associated set of gateway functions are defined: administrative gateways, 
technology gateways, and model gateways. Administrative gateways are defined to control interactions across 
administrative domain boundaries. Management technology gateways are developed to adapt between the 
various technologies that are present in the heterogeneous network infrastructure and the chosen 
communications technology. (One example of technology gateways is described in detail later). Likewise, 
management model gateways are developed to adapt between the management model domains and the 
abstractions which are defined in order to mask the network heterogeneity. 
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THE PROSPECT NETWORK 

The figure above illustrates the key components of the integrated network management system implementation, 
and sets the scope for the work presented here. Three components are to be highlighted: the ATM network and 
its associated TMN OSs (S_OS, N_OS, QA); the VPN management system components (VPN); and the 
gateway mediating management information communications between the two first systems (Gateway). 

All management components of the system shown in the figure are developed by the Prospect consortium. The 
public network domain part, managed with a TMN-structured system, provides for external access via a CMIP- 
based TMN X interface for ATM VP service management by the customer (i.e., the VPN provider). 

A management technology gateway (CMIP/CORBA interaction gateway) is located in the public network (PN) 
domain. In the VPN domain management model gateways are located which adapt (transform) the ATM VP 
service management model to the VPN domain abstraction. 

This in turn serves the end to end VPN management functions (denoted VPN in the figure), which are accessible 
from the customer's system. Similar arrangements are made for the VPN to be able to manage the customer 
premises networks (CPN), which have SNMP management facilities. 

These components, which will be described in more detail in the following, all contribute to the integration of 
network management. In particular: the VPN is mainly concerned with multi-owner, multi-technology and 
service management integration; the ATM TMN components are mainly concerned with multi-vendor 
integration; the CORBA/CMIP gateway is concerned with multi-technology integration; the CPN management 
component is mainly concerned with multi-vendor and multi-technology integration. 
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VIRTUAL PRIVATE NETWORK 



The basic role of the VPN is to provide an integrated management service allowing users to manage their 
communications on a global scale, and based on the assumption of a global, heterogeneous network 
infrastructure. Therefore, the VPN is a good example of an integrated network management system, and 
furthermore, it has also commercially attracting characteristics [Louis95]. User access to the VPN management 
services can be mediated by human-machine interfaces (GUI), and by machine-machine interfaces, for 
automatisation purposes. Prospect's VPN service is designed for decentralised control and co-operation among 
VPN providers in order to establish broader scope VPN services. 

For the realisation of the VPN service, a CORBA 2.0 compliant ORB implementation is used. The object 
oriented architecture of CORBA is suited for the implementation of systems based on distributed architectures. 
The object based nature of CORBA ensures a high level of maintainability and allows the development of more 
extensible applications. The focus on well-defined language-independent interfaces, as the starting point for 
implementation, facilitates the separation of large designs into smaller and more manageable components, and 
enables the development of reusable components. 

The COS Naming service (specified by OMG) is used to provide location transparency in the distributed VPN 
system. The naming structure is hierarchical and the service can be federated, which is a mandatory feature 
when used in a distributed multi-domain management system. In Prospect, the Naming Service is used in a way 
which balances the convenience of having globally accessible objects with the performance and security issues. 
Each site can run a local instance of the Naming Service to handle local objects, and still gain/provide access to 
global objects by using a root-level entry, which points to the global instance (or set of instances) of the Naming 
Service. 

An important aspect of CORBA based applications is the granularity of CORBA objects. CORBA is ideal for 
providing access to 'big' 'low granularity' controller objects offering complex functionality (e.g. wrapping 
legacy application, CMEP agent role). Whether CORBA is suitable for high granularity object models is more 
doubtful. Use cases which involve a huge number of CORBA objects will result in a lot of design problems 
concerning transactions, persistency, security, location etc., which may lead to an unacceptable performance of 
the application. 
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WEB-BASED USER ACCESS TO THE VPN 

The VPN Management system depends, as mentioned ealier, on three types of gateways in order to bridge the 
differences in the heterogeneous network environment. One technology (CORBA/CMIP) gateway is described 
elsewhere in this paper. The administrative gateway, which presents the Xvp n . uscr interface to the customer, is an 
implementation of the Service Subscription Model from the TINA Service Architecture. It is a reusable 
component that is used on various levels of the Prospect system, and it has been adapted to the specific needs of 
the VPN system as a connection management service, as opposed to a "traditional" information management 
service. This gateway enables the VPN customer to use the VPN service in way that is as generic and service- 
independent as possible. 

The management model gateway is intended to alleviate the differences in the various management models 
(SNMP/CMIP) in order to be able to handle the different network technologies in a uniform way. The 
funtionality needed for this is divided into three parts: (1) the handshaking procedure, which allows cooperation 
between domains that have different technology-specific demands, (2) an object that presents each domain's 
VPN system with exactly the level of end to end information it needs, and (3) an object which handles low-level 
API peculiarities. 

Java, CORBA and Web technologies are used to visualise information and behaviour of the VPN application. 
The VPN GUI is implemented as a Java applet, which enables distribution of the GUI to all computers running 
a standard web browser. The Web technology facilitates the distribution of the customer user interface and 
access software for a CNM service to a user, by use of applets which can be downloaded from the providers 
Web server. 

The VPN GUI is based on configuration, fault and QoS management information from the VPN application. 
The information is provided by APIs in the VPN application and by asynchronous events from the VPN. When 
changes occur in VPN resources, notifications are emitted to a notification server, which distributes the 
notification to subscribing clients (e.g. GUI). The notification server is inspired by ITU CMIS event 
management and COSS event service specifications. 
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# i Topological Points 



ATM NETWORK MANAGEMENT 

The VPN services offered by the VPN management system is based upon an ATM network infrastructure, 
where the network infrastructure is constituted by a number of interconnected ATM cross connects at four 
European sites: Berlin, Dublin, London and Copenhagen. Each of the four sites represents a separate 
administrative domain within the public ATM network. The network OS'es at the four administrative domains 
cooperates in order to provide a fully manageable pan-European VP layer network domain. The ATM VP 
management service offered by the public network is provided through an OS giving a top level view of the VP 
layer network domain, where each of the separarate administrative domains is viewed as a subnet partition in 
the VP layer network domain. Prospect applies a distributable object model, where the management and control 
of the subnetwork partitions can be arbitrarily distributed among the coorporating network OS'es. The location 
of the OS giving the top level view on the combined network is configurable and the service can be moved to or 
duplicated by other OS'es giving their own view of the network. 

The public ATM network VP service is fully implemented within the CMIS/CMIP technology domain using the 
Q3ADE TMN development tool. The service provided by the network OS'es to adjacent or higher layer 
management systems is offered through TMN X interfaces. The choice of the CMIS/CMIP technology to 
implement the public network services is to some extent historical, since the public network management 
system is based on the system and concepts developed in PREPARE [Lewis96], but mostly due to the structure 
of the problem domain. ATM networks are highly complex and the adopted objects models are very fine 
grained and results in a huge number of object instances. As explained earlier the current set of services offered 
within the CORBA domain seems inadequate when dealing with large and fine grained models, whereas 
CMIS/CMIP with the scoping and filtering capabilities has proven to be a strong technology for such 
applications. It is however recognised that the ATM VP service users in many cases will be in the CORBA 
domain. A CORBA/CMIP gateway is therefore included as part of the public network service offering. The 
network model applied within the public network is based on the ETSI NA43316 Generic Object Model Library 
(GOM), which has been specialised to the ATM technology. The fundamental idea behind the GOM network 
model is the break down of subnetworks into subnetworks interconnected by links (as illustrated in the figure 
above). This decomposition process stops at the lowest level where a subnetwork is "equal" to a crossconnect. 
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ATM NETWORK MANAGEMENT DISTRIBUTION 

The network OS'es assume that the network element level is controllable via Q3 interfaces giving an ITU-T 
L751 compliant view of the ATM network elements. This is realised within Prospect by providing 1.751 
compliant Q-adaptors for the ATM cross-connects constituting the ATM network infrastructure. 

The recursive layering of NE-OS and N-OS provides a single entry NE-OS for a given required functionality for 
the various divisions of the network, and thereby providing facilities for end to end management. 

The ETSI GOM library seems to favour a centralised network management, as indicated in the figure above. 
The issue of the distribution of the network management application both between different administrative 
domains but also the distribution of the application within an adminstrative domain is in general an area, where 
the standardisation on the network management issues are falling short. The distribution question is in particular 
relevant for ATM networks, where the granularity of the object model and the vast number of object instances 
renders a centralised management application inadequate for large ATM networks. One of the main issues 
addressed by the Prospect network modelling work, has therefore been to specialise the GOM model to promote 
a decentralised view of the network mangement application in favour of the traditional view of a centralised 
network management application controlling a number of network element agents. 

An issue when implementing a decentralised network mangement application is to allow for a distributed route 
determination process, and to allow for subnetworks at higher partitioning levels to make qualified route 
decisions concerning routes through an opaque subnetwork at a lower partitioning level. The concept of opaque 
subnetworks and associated concepts for the handling of these within a network OS provides the means to 
distribute the implementation of the network service at will. In order to facilitate opaque subnetworks Prospect 
has added route managed objects to the network model. Within the partitioning hierachy the route managed 
object allows subnetworks at higher partitioning levels to query route information from subnetworks at a lower 
partitioning level in order to make qualified decisions about which subnetworks a requested connection should 
be routed through. 
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CORBA/CMIP INTERWORKING 

Within the overall system a technology gateway is used to bridge between the CORBA and the CMIS/CMIP 
communications technology domains. The CORBA/CMIP gateway allows the CORBA VPN functionality to 
access and control the service provided by the public CMP based ATM VP service provider. 

The CORBA/CMIP gateway maps the services offered by the ATM VP service management system into the 
CORBA technology domain. With the use of the gateway the ATM VP service can be seen as any other 
CORBA based service offering. The change in management technology hereby becomes invisible to the VPN 
functions. 

The service offered by the ATM VP service management system via its CMIP/CMIS based TMN X interfaced 
is defined with the GDMO model accessible through the interface. The gateway represents this service in the 
CORBA domain, by translating the GDMO model into equivalent IDL definitions and offering these IDL 
interfaces at its CORBA server interface. CORBA invocations on the IDL interfaces are translated into 
equivalent CMIS requests by the gateway and forwarded to the underlying ATM VP Service management 
service. The general approach is illustrated in the figure above, where a CORBA based client will create an IDL 
proxy object which will connect to the corresponding IDL adapter object in the gateway process. Any 
invocation on the IDL adapter object in the gateway process will be translated to CMIS request and issued to the 
GDMO managed object in the OSI Agent to which the IDL adapter object corresponds. 

The rules for mapping the GDMO specifications into equivalent IDL definitions are defined by the Joint Inter- 
Domain Management working group (JIDM). 

JIDM is an activity jointly sponsored by X/Open and the Network Management Forum. The JIDM project was 
initiated in a response to the perceived need to provide tools that would enable interworking between 
management systems based on different technologies, notably OSI and SNMP network management and 
CORBA-based management frameworks. 
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CORBA/CMIP GATEWAY 

The gateway work within Prospect was divided into two stages. The first stage involved the specification and 
implementation of an initial gateway, which supported the basic CMIP-CORBA interworking required in the 
integrated network management system presented earlier. 

The second stage involved the specification and implementation of a gateway, which addressed more advanced 
aspects of CORBA-CMIP interworking, such as event handling, name resolution, scoping, and filtering. The 
second stage of the gateway work included the use of the CORBA Dynamic Skeleton Interface (DSI) and a 
GDMO to IDL compiler capable of producing translation tables (as illustrated in the figure above). 

The use of the DSI and automatic translation tables eliminated the need for the gateway process to have 
compile-time knowledge of the GDMO models of the underlying OSI agents. The second stage therefore 
provided the implementation of a GDMO model independent and dynamically re-configurable gateway process. 
The technology gateway hereby to a far extent becomes invisble to the service users in the CORBA domain. 
Any new service offering in the CMIP domain can be made visible in the CORBA domain by updating the 
gateway with the GDMO information model attached to the new CMIP based service. Doing so will make the 
CMIP based service available in the CORBA domain as any native CORBA based service. 

The CORBA/CMIP gateway in itself provides both CMIP and CORBA based management interfaces, which 
allows for remote and dynamic update of the mapping information. The gateway can consequently be managed 
either by entities in the CORBA domain or by entities in the CMIP domain. Within Prospect the CORBA/CMIP 
gateway belongs to the public network domain, which with the gateway makes the public network services 
available in the CORBA domain. The gateway could however also have been placed in the service user domain 
(the VPN), or in the administrative domain of a third party service provider offering technology gateway 
services. 
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CONCLUSIONS 

The experience gained from developing the integrated network management system presented here shows that it 
is indeed possible to provide the types of network management integration required to enable automated end to 
end communications management across the domain boundaries of a heterogeneous network infrastructure. It 
also shows that CORBA is feasible for developing such systems at the service management layer, and that the 
application of CORBA does not violate any TMN architectural principles. Rather, CORBA is becoming a 
realistic TMN realisation technology. However, OSI-based TMN is still superior in some respects, due to its 
ability to handle large numbers of managed objects (e.g., by OSI's naming scheme and by encapsulation), and 
due to the large number of management functions that are standardised and available in commercial TMN 
platforms. This is one of the reasons why gateways are central components for integrating network 
management. Even more so, as SNMP and OSI agents are deployed in a huge range of existing and installed 
networking equipment. 

Our experience also shows that TMN is a feasible integration architecture. The functionality of the system can 
be easily explained in terms of TMN function blocks, and the various gateway types needed also maps easily 
onto TMN building blocks: technology gateways are basically Q Adaptors, model gateways are Mediation 
Functions or Information Conversion Functions, and administrative gateways functions are functions located 
near the X interface. The development work was undertaken by several companies, each developing a set of the 
components described here. Driven by common goals and a clear division of labour, in accordance with 
Prospect's "service value-chain", it was even possible to integrate the various components in a relative 
unproblematic manner. In the remaining time of the project this system is being extended further, for example, 
integrated fault and performance management functionality will be added, and CMIP/SNMP gateways will be 
included, and end-user access to management information through a TMN WSF with Java and directory 
gateways will be provided. 
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